🏁 Script executed:

#!/bin/bash
python - <<'PY'
import re
from collections import defaultdict
from pathlib import Path

text = Path("cloud-controlplane/cloud-controlplane.yaml").read_text()

in_paths = False
paths = []
for line in text.splitlines():
    if line.strip() == "paths:":
        in_paths = True
        continue
    if in_paths and re.match(r'^\S', line):
        break
    m = re.match(r'^  (/[^:]+):\s*$', line)
    if in_paths and m:
        paths.append(m.group(1))

normalized = defaultdict(list)
for path in paths:
    normalized[re.sub(r'\{[^}]+\}', '{}', path)].append(path)

for key, variants in sorted(normalized.items()):
    if len(variants) > 1:
        print(key)
        for variant in variants:
            print(f"  - {variant}")
PY

Repository: redpanda-data/api-docs

Length of output: 522

🏁 Script executed:

#!/bin/bash
set -euo pipefail

FILE="cloud-controlplane/cloud-controlplane.yaml"

echo "=== Find /v1/networks/{id} path block ==="
rg -n --fixed-string '  /v1/networks/{id}:' "$FILE" -n || true
python - <<'PY'
from pathlib import Path
import re

p=Path("cloud-controlplane/cloud-controlplane.yaml")
lines=p.read_text().splitlines()

# find indices for the two path keys
targets=["  /v1/networks/{id}:","  /v1/networks/{network.id}:"]
for t in targets:
    idx=[i for i,l in enumerate(lines) if l.strip()==t.strip()]
    print(t, "count", len(idx), "indices", idx[:5])
    if idx:
        i=idx[0]
        # print from a bit before to a bit after
        start=max(0,i-5); end=min(len(lines), i+60)
        print("\n--- Context for", t, "lines", start+1, "-", end, "---")
        for k in range(start,end):
            print(f"{k+1:>6} {lines[k]}")
PY

echo "=== Find all operations directly under those two path keys (method lines) ==="
python - <<'PY'
from pathlib import Path
import re

FILE=Path("cloud-controlplane/cloud-controlplane.yaml")
lines=FILE.read_text().splitlines()

def collect_methods(path_key):
    methods=[]
    # find line with exact key
    idx=None
    for i,l in enumerate(lines):
        if l.strip()==path_key.strip():
            idx=i
            break
    if idx is None:
        return methods
    # scan until next top-level path key (2 spaces indent, starts with /)
    for j in range(idx+1,len(lines)):
        l=lines[j]
        if re.match(r'^  /[^:]+:\s*$', l.strip()):
            break
        m=re.match(r'^\s{4}([a-z]+):\s*$', l)  # 4 spaces then http method
        if m:
            methods.append(m.group(1))
    return methods

print("methods for /v1/networks/{id}:", collect_methods("  /v1/networks/{id}:"))
print("methods for /v1/networks/{network.id}:", collect_methods("  /v1/networks/{network.id}:"))
PY

Repository: redpanda-data/api-docs

Length of output: 6784

🌐 Web query:

OpenAPI 3 duplicate/conflicting path templates different parameter names {id} vs {network.id} validator behavior

💡 Result:

In the OpenAPI 3 specification, paths that share the same hierarchy but use different parameter names in their templates (such as /users/{id} and /users/{network.id}) are considered identical and are strictly invalid [1][2][3]. The OpenAPI Specification explicitly states: "Templated paths with the same hierarchy but different templated names MUST NOT exist as they are identical" [1][3]. Because OpenAPI tooling normalizes these templates by treating the placeholder (the text inside the braces) as a generic segment, both {id} and {network.id} are effectively reduced to the same internal signature (e.g., /users/{}). Validator behavior typically includes the following: 1. Invalid Specification: Most linters and schema validators will flag this as an error because the structure is ambiguous and violates the specification's uniqueness requirements [4]. 2. Tooling Failure: Code generators and diffing tools often fail when they encounter these paths because they cannot distinguish between the two templates, leading to errors like "Two path items have the same signature" [4]. 3. Ambiguous Routing: If a validator fails to catch this, actual API routing becomes ambiguous. Since the specification considers them identical, there is no standardized behavior for how an API server or client should resolve which path to use, and it is left to the individual implementation [1][2]. To resolve this issue, you must use consistent parameter names across identical path structures or restructure your API to ensure the paths themselves are distinct (e.g., /users/{id} vs /networks/{network.id}/users/{id}) [5][4].

Citations:

• 1: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.4.md
• 2: https://spec.openapis.org/oas/v3.2.0.html
• 3: https://swagger.io/specification/
• 4: Two path items have the same signature OpenAPITools/openapi-diff#468
• 5: Ordering of matches when no path is concrete OAI/OpenAPI-Specification#2356

🌐 Web query:

OpenAPI path parameter name constraints allow dots '.' in {parameterName}

💡 Result:

In OpenAPI, dots '.' are allowed in the path parameter name (the identifier inside { }), as the spec does not restrict the parameter-name characters to exclude '.'. [1] What OpenAPI does restrict is the content/value of a path parameter: the path parameter value MUST NOT contain any unescaped “generic syntax” characters described by RFC3986: forward slashes (/), question marks (?), or hashes (#). This restriction is about the parameter value at runtime, not the name/identifier inside the curly braces. [2][3] So {user.name} as a template name is permitted by the OpenAPI rules, but the actual value substituted for {user.name} cannot include unescaped '/', '?', or '#'. [1][2]

Citations:

• 1: Path Templating: is there a restriction on the path parameter name? OAI/OpenAPI-Specification#1969
• 2: https://swagger.io/specification/
• 3: "path parameters MUST NOT contain any unescaped “generic syntax” characters" OAI/OpenAPI-Specification#2804